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Mail Priority 


In RFC 539 (NIC--17644,3d:gy) Postel and I suggested that mail 
senders be allowed to assign a degree of priority to their mail. 
White (RFC 555--17993,6c:gy) objected to defining shades of urgency, 
without having their effects upon the Mail Protocol server also 
defined. 


If priority levels were to be assigned by automata, I would agree 
with Jim. Unfortunately, the human sender of the mail will usually 
be the one to assign the priority, and humans will not be consistent 
in that assignment. 


Also unfortunately, the concept of urgency is an integral part of 
communication. If it weren’t, we could ignore its inclusion into the 
MP. 


Since distinctions in urgency are useful (necessary?) and since 
humans will be the ones assigning specific degrees of urgency 
(thereby making it impossible for server processes to automatically 
do the "right thing" in response), we suggested only including the 
INFORMATION as part of the protocol. Let the human and server- 
process receivers decide between themselves how the server-process 
should deal with that information. 


Now that I have argued all that, let me suggest interpretations for 
urgency values. This is so that programmers can have automata- 
generated mail (e.g., notification of the status of previously sent 
mail) carry reasonable urgency values: 


10 Phone in the middle of the night, if necessary. 

9 

8 Deliver to user’s terminal NOW. 

7 

6 Deliver to user’s terminal only if user is at "exec" 

level. 

5 

4 Deliver immediately after sign-on or before sign-off. 
3 

2 Deliver into standard mailbox. 

1 

QO Junk Mail 
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